The client-server relationship has opened vast areas of network operability. Whether implemented in a local area network (LAN) or the Internet, the interaction between client entities and a centralized server forms the basis of the computing world today. Applications routinely incorporate remote use of data or logic to manage inventory, employees, sales, and other such activities. Early client-server applications involved remote access to databases to provide data for locally running applications. The management of such distributed functionality has advanced with several programming techniques and architectures. MICROSOFT CORPORATION′S Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA), developed by Object Management Group, are just two examples of architectures and specifications that allow programs at different locations, and possibly developed by different vendors, to communicate in a network through an interface broker.
With CORBA, the essential concept is the Object Request Broker (ORB). ORB support across a network of multiple computers with multiple clients and servers allows for a client program to request services from a server program or object without having to completely understand where that server program or object is, or what the interface to that server program or object requires. ORB's communicate requests and return replies by using the General Inter-ORB Protocol (GIOP) and, when used across the Internet, Internet Inter-ORB Protocol (IIOP). IIOP generally maps GIOP requests and replies into the Transmission Control Protocol (TCP) layer for each computer. Thus, the interfacing of the different entities is transparent to the user. DCOM works in a similar manner using TCP/Internet Protocol (TCP/IP) and hypertext transfer protocol (HTTP) to communicate remote procedure calls (RPCs) to the compatible server objects.
Both DCOM and CORBA follow a similar step-by-step process. A local application or object requests services from another, remote object. The remote object is located using the class ID (CLSID), for DCOM, or client ORB, for CORBA. This broker or agent arrangement operates in a similar manner to the stub and skeleton architecture used in Remote Procedure Call (RPC) communication. The stub, which is a small piece of communication code on the client system, operates as the proxy with the remote server, performing all communications with the skeleton, which is the corresponding communication code on the remote server. Therefore, the client does not have to address the different interface possibilities with the remote server. Once the request for service has reached the server object at the remote server, an instance of the object is downloaded to the client. The client may then run the instantiated object locally using the local user interface.
The common thread with DCOM and CORBA is that the distributed management performed by each architecture is directed to distributed computing. Code may be persistent between sessions and RPCs; data is not. Therefore, while logic may persist between sessions, data is only session-specific.
Another tool of distributed or remote interactive computing is the cookie. A cookie is data created by a server-side connection, such as a common gateway interface (CGI) script, that can be used to both store and retrieve information on the client side of the connection. This addition of a simple, persistent, client-side state significantly extends capabilities of Web-based client-server applications. The standard specification for cookies began with NETSCAPE COMMUNICATION CORPORATION's “Persistent Client State HTTP Cookies” and continues with RFC 2109—“HTTP State Management Mechanism” issued by the Network Working Group of the Internet Engineering Task Force (IETF). These specifications define a size limit of 4096 bytes per cookie. Moreover, a limit of 20 cookies per Web server is also defined, which means than any one Web server can store a maximum of 20 4096-byte cookies on every client computer.
Cookies provide a way for Web sites to keep track of user patterns and preferences, and, with the cooperation of the Web browser, store the cookies on the client computer. Hypertext Transfer Protocol (HTTP), which is the transfer protocol of the Web, is a stateless protocol, such that each request for a Web page is independent of all other such requests. Therefore, the Web page server has no memory of the current state (i.e., what pages or information has previously been sent to or exchanged with the client computer). Cookies provide the ability for the user to experience a personalized session by providing the Web page and Web page server data that creates a remembered state of the user Web interaction.
In a typical example of operation, when a user at a client computer runs its Web browser and types in a Universal Resource Locator (URL), such as www.macromedia.com, the browser communicates with the Web server and requests the macromedia.com home page. On the client-side, once the request is made, the browser searches its cookie file for cookies designated for macromedia.com. If none are found, no cookies are sent. On the server-side, the macromedia.com Web server receives the request and attempts to read any cookies that may be transmitted from the requesting browser. If none are available, the Web server determines that this is the first time the client-browser has visited the macromedia.com Web site. The macromedia.com Web server may then direct that a cookie or cookies be saved onto the client computer marking the visit and identifying the client-side computer. When the client computer next makes a request for the macromedia.com home page, it will now typically send the cookies designated for the macromedia.com Web site. The macromedia.com Web site will read the cookies and be able to adjust the user experience at the client-side using this “state” information.
Some cookies persist only until the end of a specific browser session. Meaning that when the browser program is closed, the cookies are erased. However, when some cookies are created, they include an expiration date after which the cookie will expire and be erased from the designated cookie file. Thus, those cookies persist from one browser session to another residing on the client computer until the expiration date has been reached. Cookies may also be erased if the maximum cookie limit, which is a standard specification, is exceeded. In this situation, the most least accessed cookies will typically be deleted first. Therefore, most cookies are set once and then go away either (1) at the close of the current browser session; (2) until the cookie expiration date is reached; or (2) when the maximum number of cookies has been exceeded.
Cookies provide an adequate tool for simple Web interactions, such as remembering login information, setting up a shopping cart in an e-commerce Web site, or tracking user history information. However, for more complicated distributed Internet applications, cookies are somewhat inadequate. Cookies are limited solely to text formatting. Therefore, they can provide no distributed functionality or logic. Cookies are also single-version data. Once the cookie information is set, it does not change until the cookie expires. New information must generally be saved as a new cookie. Furthermore, cookies are accessible by URL paths, so the capability exists for many different URLs may have an opportunity to use that information by including many different URLs in the path property of the cookie.